WORLD INTELLECTUAL PROPERTY ORGANIZATION
International Bureau
PCT
INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
(51) International Patent Classification 6
H04L 9/32
Al
(11) International Publication Number: WO 99/21321
(43) International Publication Date: 29 April 1999 (29.04.99)
(21) International Application Number: PCT/US98/22162
(22) International Filing Date: 20 October 1998 (20.10.98)
(30) Priority Data:
08/954,245
20 October 1997 (20.10.97)
US
(71) Applicant: CRYPTOWORKS [US/US]; 1385 Sir Francis
Drake Boulevard, San Anselmo, CA 94960 (US).
(72) Inventor: LEBOURGEOIS, John, H.; 193 San Carlos Way,
Novato, CA 94945 (US).
(74) Agent: WOLFELD, Warren, S.; Fliesler, Dubb, Meyer and
Lovejoy LLP, Suite 400, Four Embarcadero Center, San
Francisco, CA 94111-4156 (US).
(81) Designated States: AL, AM, AT, AU, AZ, BA, BB, BG, BR,
BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB, GD,
GE, GH, GM, HR, HU, ID, IL, IS, JP, KE, KG, KP, KR,
KZ, LC, LK, LR, LS, LT, LU, LV, MD, MG, MK, MN,
MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK,
SL, TJ, TM, TR, TT, UA, UG, UZ, VN, YU, ZW, ARIPO
patent (GH, GM, KE, LS, MW, SD, SZ, UG, ZW), Eurasian
patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European
patent (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR,
IE, IT, LU, MC, NL, PT, SE), OAPI patent (BF, BJ, CF,
CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG).
Published
With international search report
Before the expiration of the time limit for amending the
claims and to be republished in the event of the receipt of
amendments.
(54) Title: DIGITALLY CERTIFYING A USER IDENTITY AND A COMPUTER SYSTEM IN COMBINATION
(57) Abstract
Payment Info
sd- Real Time Signature
s+ Challenge Code
Certiflcatiorv
Result x _ m
USER
(PURCHASER)
Real Time
Signature
1. Original
Signature
Digital certification
method in which a first digital
signature dependent upon a
first user (102) and a first user
(102) system in combination
(102), is stored accessibly to
a certification server (108),
The first user (102) identity
can be distinguished by, for
example, a PIN provided by
the user (102). Subsequently,
at a second time when
the user (102) desires
authorization to complete
a transaction (2), the user
system (102) generates a
second signature dependent
upon both the current user
identity and current user
system in combination.
The certifying system (104)
then compares the second
signature with the first (1) as """"""
stored (108), in order to determine whether to certify the transaction (6). The certification can accommodate normal computer system
component drift. In an embodiment, an inquiring system (106) desiring to confirm the identity of a user (102), issues a challenge code (3)
to the user system (102). The user system (102) then digests the user's PIN, individual component signatures as they currently exist on
the user's system (102), together with the challenge code (3) to generate the new signature (4). The new signature (4) is transmitted back
to the inquiring system (106), which transmits it on to the certification server (104) together with the challenge code (5). The certification
server (104) then digests the challenge code with the original signature (1) as previously stored (108), and compares the result to the newly
provided signature. If they match, then the user's (102) identity is confirmed (6). If not, then drift criteria can be applied if desired.
•< FINANCIAL
CLEARINGHOUSE
(TRUSTED CERTIFICATION
SERVER)
•^08
SIGNATURE
DATABASE
FOR THE PURPOSES OF INFORMATION ONLY
Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT.
AL
Albania
ES
Spain
LS
Lesotho
SI
Slovenia
AM
Armenia
FI
Finland
LT
Lithuania
SK
Slovakia
AT
Austria
FR
France
LU
Luxembourg
SN
Senegal
AU
Australia
GA
Gabon
LV
Latvia
SZ
Swaziland
AZ
Azerbaijan
GB
United Kingdom
MC
Monaco
TD
Chad
BA
Bosnia and Herzegovina
GE
Georgia
MD
Republic of Moldova
TG
Togo
BB
Barbados
GH
Ghana
MG
Madagascar
TJ
Tajikistan
BE
Belgium
GN
Guinea
MK
The former Yugoslav
TM
Turkmenistan
BF
Burkina Faso
GR
Greece
Republic of Macedonia
TR
Turkey
BG
Bulgaria
HU
Hungary
ML
Mali
TT
Trinidad and Tobago
BJ
Benin
IE
Ireland
MN
Mongolia
UA
Ukraine
BR
Brazil
IL
Israel
MR
Mauritania
UG
Uganda
BY
Belarus
IS
Iceland
MW
Malawi
US
United States of America
CA
Canada
IT
Italy
MX
Mexico
UZ
Uzbekistan
CF
Central African Republic
JP
Japan
NE
Niger
VN
Viet Nam
CG
Congo
KE
Kenya
NL
Netherlands
YU
Yugoslavia
CH
Switzerland
KG
Kyrgyzstan
NO
Norway
ZW
Zimbabwe
CI
Cdte dTvoire
KP
Democratic People's
NZ
New Zealand
CM
Cameroon
Republic of Korea
PL
Poland
CN
China
KR
Republic of Korea
PT
Portugal
cu
Cuba
KZ
Kazakstan
RO
Romania
cz
Czech Republic
LC
Saint Lucia
RU
Russian Federation
DE
Germany
LI
Liechtenstein
SD
Sudan
DK
Denmark
LK
Sri Lanka
SE
Sweden
EE
Estonia
LR
Liberia
SG
Singapore
WO 99/21321
PCT/US98/22162
-1-
DIGITALLY CERTIFYING A USER IDENTITY AND A COMPUTER SYSTEM IN COMBINATION
BACKGROUND OF THE INVENTION
1. Field Qf the In vention
The invention relates to digital certification
techniques and, more particularly, to a technique for
5 certifying a user identity and computer system in
combination.
2. Description of Related Art-.
Digital commerce on the Internet requires the
10 ability to digitally "sign" messages, providing a level
of assurance that the purported sender of the message
is in fact the true sender of the message. Commonly,
a digital signature is created by encrypting a digest
of the message with the sender's private key. In order
15 to verify authorship, the recipient of the message
decrypts the digital signature using the public key of
the purported sender to recover the original digest,
and compares the result to the recipient's own digest
of the message as received.
20 The reliability of the signature verification
depends on the reliability of the recipient's copy of
the sender's public key. Often the sender transmits
such a copy of his or her public key along with the
original message, as a courtesy. Therefore, one
25 possible way of subverting the digital signature
technique is that an impostor might create a message
purportedly from the original sender, and encrypt a
digest of the message according to a different private
key. The impostor would then send the message on to
3 0 the recipient with the new encrypted digest and with
the public key corresponding to the impostor's private
key. Assuming the recipient relies on the public key
WO 99/21321
PCT/US98/22162
-2-
received with the message in order to verify the
authenticity of the message, then the recipients
verification that the message originated from the
original sender will be false .
5 One known method for preventing this kind of
subversion involves the use of digital certificates,
for example as set forth in International
Telecommunication Union, "Recommendation X.509
Information Technology - Open Systems Interconnection -
10 the Directory: Authentication Framework" (11/93)
("Recommendation X.509"), incorporated herein by
reference. According to this standard, the sender
transmits the original message and encrypted digest in
conjunction with a digital certificate. To create the
15 certificate, the sender passes the sender's public key
through the message digesting algorithm to form a
digest for the sender's public key, which is then
encrypted by a third party certifier using the
certifier's private key to form an encrypted digest of
20 the sender's public key. The certifier may be any
third party who is trusted by the recipient to not be
subject to subversion by the impostor. The sender then
transmits to the recipient the original desired
message, the encrypted digest for the original message,
25 and the certificate (including the sender's public key
and the encrypted digest of the sender's public key).
As with the non- certificated transmission, the sender
may include the certifier's public key as part of the
certificate .
3 0 In order to verify the authenticity of the
message, the recipient uses the sender's public key,
from the certificate, to verify the authenticity of the
message itself in the manner described above. The
recipient also uses the certifier's public key to
WO 99/21321
PCT/US98/22162
-3-
verify the authenticity of the encrypted digest in the
certificate of the sender 1 s public key.
But a certification scheme is also subject to
subversion in the same manner as the non- certificated
5 scheme if the recipient still must rely on the validity
of the certifier's public key as provided in the
certificate to determine the authenticity of the
certificate itself. The X.509 scheme, therefore,
envisions a hierarchy of certifying authorities, each
10 certifying the public key of one or more other
certifying authorities, until a certification chain is
created from the original sender of the message up to
some universally trusted certifying authority (referred
to as the Root Authority (RA) ) .
15 The X.509 standard for signing messages suffers
from a number of drawbacks, not the least of which is
that no universally trusted RA currently exists . A
number of different entities aspire to that role, but
none is currently universally accepted. The necessary
2 0 hierarchy of certifying authorities is not currently in
place. Another deficiency involves the complexity of
the certification and verification process which
involve multiple layers of certifications. In addition,
even if the hierarchy of certifying authorities were in
2 5 place, and the RA were accepted as trustworthy, the
X.5 09 standard still may not reliably bind a digital
signature to an individual . Rather, binding is based
only on the preponderance of the evidence that at some
time in the past, the signer was in fact the individual
3 0 that he or she purported to be.
Another deficiency with the X.509 standard is
that, as proposed, every validation by a certifying
authority is likely to incur a fee. Another problem is
that the X.509 scheme depends on users abiding by
WO 99/21321
PCT/US98/22162
certain policies and constraints promulgated in the
various certifying hierarchies, such as expiration
dates and certificate revocations. Moreover, the
policies and constraints promulgated in different
5 hierarchies can be different. A number of other
deficiencies also exist in the X.509 scheme.
Different kinds of transactions require different
degrees of confidence in the validity of a digital
signature. For example, whereas large dollar amount
10 transactions, stock trading, weapons release, and so on
might require a high level of confidence, smaller
transactions might not require such a high level of
confidence. Very small cash transactions or non-
transaction communications might not require very much
15 confidence at all in the validity of the digital
signature. For communications and transactions not
requiring the highest level of confidence in the
digital signature, an alternative to the X.509
hierarchical model exists. This alternative, known as
2 0 Pretty Good Privacy (PGP) , proposes a diffuse network
model, where networks of people "sign" a given user's
public key on a public key server. Public keys thereby
gradually accumulate sufficient "mass" to vouch for the
identity of the owner of the public key. The PGP
25 scheme avoids some of the problems with the X.509
standard, but lacks any means for accountability.
Thus, of the two primary conventional cryptographic
techniques for binding the sender of a message with an
identity, one is unwieldy and requires an
3 0 infrastructure that is not currently in place, and the
other is not sufficiently binding or accountable to be
used in high-risk transactions.
Certain classes of transactions exist which do
not require the binding of the sender of a message with
WO 99/21321
PCT/US98/22162
-5-
an individual. For example, authorization transactions
do not require that the individual requesting
authorization be identifiable by the authority of which
authorization is being requested. The identity of the
5 individual may be, for example, on file at a bank.
What is important for these transactions is that the
identity of the user be consistent, not that the
individual be known. For the use of an automated teller
machine, for example, the user need only enter an
10 account number and PIN (personal identification
number) . The identity of the individual is not
transmitted for the authorization transaction; only a
representation, in the form of the user's PIN and the
number recorded on the ATM card is transmitted.
15 Authorization certifications usually have only a one-
tier hierarchy, such as where a bank or credit card
company previously issued the user an I.D. on the basis
of the user's account with the bank or credit card
company. They usually do not rely on a chain of
20 certifying authorities to validate the user. One-tier
authorization certification thereby avoids any need for
a hierarchy infrastructure as in the X.5 09 standard.
By foregoing the necessity of a binding between a user
and a known individual, these systems also avoid any
25 need for a sufficient mass of signers on a public key
server to vouch for the identity of the user, as in the
PGP scheme.
In U.S. Patent Application SC/Serial No.
08/818,132, filed March 14, 1997, entitled "DIGITAL
3 0 PRODUCT RIGHTS MANAGEMENT TECHNIQUE", by inventor
John H. LeBourgeois, incorporated herein by reference
in its entirety, an enhanced authorization mechanism is
described which binds an authorization requestor to a
particular computer system, for example, rather than to
WO 99/21321
PCT/US98/22162
-6-
a particular individual. Such a mechanism is useful,
for example, for ensuring that digital products, such
as software, music, images and so on, be authorized for
use only on a single computer. Anonymity (privacy) of
5 the individual user can be maintained. As set forth in
the above -incorporated patent application, a "reader
system signature" is developed at the time the product
is to be used on the reader system, based on
identifying information of certain hardware or software
10 components then on the system. The reader system is
able to make use of the digital product only if the
proper system signature exists. A certain amount of
flexibility is built into the process, because if
validation at the time of use fails, a revalidation
15 process takes place whereby a license server
determines, in a sense, "how different" the reader
system is currently as compared to its configuration at
the time of the original authorization. If the reader
system as it is currently configured satisfies certain
2 0 predetermined "drift" criteria, then reauthorization is
automatic; otherwise reauthorization is made manually.
Thus the technique described in the above- incorporated
patent application permits flexible authorization- type
certification with only a single level of hierarchy and
25 while preserving the privacy of individual users.
SUMMARY OF THE INVENTION
The present invention permits the binding of a
user identity (virtual or physical) with an
30 authorization request. This binding is reliable enough
to be used in relatively high-risk transactions, and
can be made reliable enough to be used in the highest -
risk transactions. An embodiment of the invention
optionally can make use of some of the system signature
WO 99/21321
PCT/US98/22162
-7-
technology described in the above- incorporated patent
application.
According to the invention, roughly described, a
first signature dependent upon a first user identity
5 and a first user system in combination, is stored
accessibly to a certification server. The first user
identity can be, for example, a PIN provided by the
user. Subsequently, at a second time when the user
desires authorization to complete a transaction, the
10 user system generates a second signature dependent upon
both the current user identity and the current user
system in combination. The certifying system then
compares the second signature with the first, as
stored, in order to determine whether to certify the
15 transaction. The certification can accommodate normal
computer system component drift, for example in the
manner described in the above- incorporated patent
application.
It will be appreciated that such a method
2 0 minimizes the risk of a stolen PIN, because the PIN is
useless without the computer system hardware on which
the first user identity was originally established.
The technique also minimizes the risk of subversion
through the theft of the first user's computer hardware
25 because, again, the transaction will not be authorized
without the user's PIN.
In an aspect of the invention, the mechanism can
also provide a level of confidence that the second
signature, provided to the certification server at the
3 0 time that authorization is requested, truly was
generated based on the user's system components as it
existed at the time that the authorization is
requested, rather than being merely a copy of a
signature stored previously. In an embodiment, after
WO 99/21321
PCT/US98/22162
-8-
the user issues an authorization request to a merchant
system, for example, the merchant system issues a
challenge code back to the user system. The user
system then digests the user's PIN, individual
5 component signatures as they currently exist on the
user's system, together with the challenge code to
generate the new signature. The new signature is
transmitted back to the merchant server, which
transmits it on to the certification server together
10 with the challenge code. The certification server then
digests the challenge code with the original first
signature as previously stored, and compares the result
to the newly provided signature. If they match, then
the transaction is authorized. If not, then drift
15 criteria can be applied if desired.
The mechanism according to the invention has a
number of advantages over other authorization
certification techniques. For example, the
certification by nature is limited in time, since
2 0 ordinary hardware drift or new computer hardware would
invalidate previous certifications allowing new
certifications to be generated. As another example,
validation of the first user identity is self-
certifying; if the digest of the user's system is not
25 correct, the certification fails automatically. This
allows minimization of transaction costs and greater
security for on-line validation. As another example,
the certification may be ported to a smart card, with
an appropriate code indicating smart card usage and an
3 0 expiration time stamp. Furthermore, identity cannot be
loaned to another person without the other person being
present on the hardware. For the same reason, nor can
a user identity be stolen and transmitted through the
Internet. The ability for self - certification is
WO 99/21321
PCT/US98/22162
-9-
present as well, leveling the entire X.509 hierarchy,
as the single certification authority can substantially
rely on the uniqueness of the certificate presented
binding the individual to the user system.
5 Certifications can now be generated in two versions:
anonymous and publicly bound. Moreover, individuals can
generate a number of different virtual user identities,
simply by using different PINs for each identity. This
improves anonymity in transactions and communications.
10 Finally, for cases where the physical identity of a
user must be bound to a machine instance, external
validation of identity can bind the person to the
hardware certification, with much more confidence and
less risk than currently exists in the conventional
15 proposed systems .
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will be described with respect to
particular embodiments thereof, and reference will be
2 0 made to the drawings, in which:
Fig. 1 is an overall symbolic diagram of an
arrangement according to the invention.
Fig. 2 is a symbolic block diagram illustrating
the structure of a typical computer system which may be
25 used as a user system, an inquirer system or a
certification server.
Figs. 3A and 3B in combination are a flow chart
illustrating the overall system flow for the embodiment
of Fig. 1.
3 0 Fig. 4 is a flow chart detail of step 314 in
Fig. 3A.
Fig. 5 is a flow chart detail of step 33 0 in
Fig. 3B.
Fig. 6 is a detail of step 336 in Fig. 3B.
WO 99/21321
PCT/US98/22162
-10-
Fig. 7 is a detail of the decision step 338
in Fig. 3B.
Figs. 8 and 9 are alternative details of step 724
in Fig. 7.
5 Fig. 10 is a detail of step 1000 in Figs. 7, 8
and 9 .
DETAILED DESCRIPTION
Fig. 1 is an overall symbolic diagram of an
10 arrangement according to the invention. The
arrangement has three primary components: a user system
102, a financial clearinghouse system 104 and a system
referred to herein as an inquirer system 106. The
financial clearinghouse system 104 can be any
15 certification server trusted by the inquirer 106, such
as a bank, a credit card company, or a third party
certifying authority. The inquirer system 106 can be
any entity that wishes to verify with the financial
clearinghouse 104 the identity of a user. In the
2 0 embodiment described herein, the inquirer 10 6 might be,
for example, an on-line merchant server system. In
conformity with this paradigm, the user 102 might be a
person interested in purchasing goods or services from
the merchant 106. In addition to the above, the
25 financial clearinghouse 104 maintains a signature
database 108, containing digital signatures of the
various accounts held by users of the financial
clearinghouse 104 .
In general operation, a user opens up an account
3 0 with the financial clearinghouse 104, and provides a
digital signature to the clearinghouse 104 for storage
on the signature database 108. As described in more
detail hereinafter, the digital signature depends upon
both the user and the user's system 102. At a
WO 99/21321
PCT/US98/22162
-11-
subsequent time, when the user wishes to purchase
merchandise from the merchant 106, the user system 102
regenerates the signature in real time, including both
the portions which depend upon the user and the
5 portions which depend upon the user's system. The
newly generated signature is provided to the financial
clearinghouse, which processes it in relation to the
digital signature originally stored on the signature
database 108 to determine whether the real time-
10 generated signature is valid.
In Fig. 1, the user system 102, the certification
server 104 and the inquirer system 106 are each
illustrated as a respective individual block.
Depending on the embodiment, each block might contain
15 no more than a single computer, or in different
embodiments, different blocks can contain more than one
computer. In one embodiment, one or more of the blocks
102, 104 and 10 6, for example the certification server
104, contains a number of computers spread out over a
2 0 great geographical area and interconnected by a
network. The illustration of the user system 102, the
certification server 104, and the inquirer system 106
as single blocks is not intended to indicate that each
must constitute only a single computer system or that
25 each must be located at a respective single location.
Nor is there any requirement that computers used
to form the user system 102, the certification server
104, and the inquirer system 106 have any particular
structure. Fig. 2 is a symbolic block diagram
3 0 illustrating the structure of a typical computer system
which may be used as a user system, an inquirer system
or a certification server. It comprises a CPU 2 02 and
cache memory 204, both connected to a CPU bus 206.
Interface circuitry 208 is also connected to the CPU
WO 99/21321
PCT/US98/22162
-12-
bus 206. The interface circuitry 208 is further
connected to a main memory 210, as well as to two I/O
buses: PCI-bus 212 and ISA-bus 214. Connected to the
PCI -bus 212 are sound and game controllers 216, a
5 network adapter 232 and a display adapter 218, the last
of which is further connected to a monitor 220.
Connected to the ISA-bus 214 is a hard disk drive
controller 222, a CD-ROM drive controller 224, a floppy
disk drive controller 22 6, various I/O ports 228, and
10 a boot PROM 230. Most of the peripheral components
illustrated in Fig. 2 include on-board configuration
data which can be read by the CPU 202. In addition,
the boot PROM 23 0 includes a portion which is writeable
by the CPU 202 to store configuration data. In
15 general, the software to operate the user system 102,
the certification server 104 or the inquirer system 106
is stored on the disk drive controlled by the disk
drive controller 222, and brought into main memory 210
as needed for execution. The computer system of Fig. 2
2 0 communicates with the other systems of Fig. 1 via the
network adapter 232.
Figs. 3A and 3B in combination are a flow chart
illustrating the overall system flow for the embodiment
of Fig. 1. The flow chart of Fig. 3A continues in Fig.
25 3B, as indicated by the circled symbol "B" in both
figures .
Referring to Fig. 3A, in a step 310, prior to any
purchasing transaction, the user presents his or her
identification to the financial clearinghouse or other
3 0 financial institution which stands behind the
certification server 104. Depending on the level of
confidence that the financial institution requires in
the physical identity of the user, the required
identification might be as strict as a biometric
WO 99/21321
PCT/US98/22162
-13-
measurement, such as fingerprints or a retinal scan, or
it may be somewhat less stringent, such as by requiring
notarization, a photo I.D., or other mechanism
involving some physical presence. In a situation where
5 the financial institution does not need to know the
physical identity at all, for example where the
financial institution is merely going to be maintaining
a debit account and is taking no risk of its own, step
310 can be omitted. For a debit account, the financial
10 institution is concerned only that the user identity be
consistent in future transactions, not that the user
identity actually be known; it is not necessary to bind
the user identity with a physical identity.
In a step 312, the financial institution
15 establishes an account for the user. This may involve
depositing some money into a debit account, or it may
involve merely creating a record of the user in a
database .
In step 314, the user, at the user system 102,
2 0 creates an original signature for a first user identity
in a manner described in more detail hereinafter. The
digital signature created in step 314 depends upon both
the user system 102 as well as the user's first
identity (the user can have more than one virtual
25 identity, if desired) .
In a step 316, the user system 102 transmits the
original digital signature to the certification server
104 which, in step 318, stores the original digital
signature in the signature database 108 in conjunction
3 0 with the user account.
Some time later, in a step 32 0, the user browses
an on-line catalog, for example, maintained by the
merchant system 106, and selects items for purchase.
In step 322, the user system 102 transmits the user's
WO 99/21321
PCI7US98/22162
payment information to the merchant system 106. Such
payment information might include credit card
information or a reference to a debit account
previously established at the financial clearinghouse
5 104. Before authorizing the transaction, the merchant
system 106 will first desire certification that the
user is in fact the owner of the credit card or debit
account .
Accordingly, in a step 324, the merchant system
10 106 generates a challenge code and transmits it to the
user system 102. The challenge code serves as an
inquiry to the user system 102 to provide information
so that the merchant can verify the identity of the
user. The challenge code preferably is generated
15 randomly, but complete randomness is not actually
required. The challenge code is also preferably
generated just prior to transmission to the user system
102, but in other embodiments, it may have been
generated earlier. It will be seen from the further
2 0 description below that the issuance of a challenge code
helps to ensure that the real time digital signature
that will next be generated by the user system 102,
truly was generated in real time, and is not merely a
surreptitious copy of a digital signature previously
25 stored on the user system 102. Different embodiments
of the arrangement of Fig. 1 might require different
levels of confidence in the currency of the real time-
generated digital signature, and therefore might permit
different freedoms in the randomness of the merchant's
3 0 challenge code or in the currency of generation of the
merchant 1 s challenge code .
In a step 326, after the user system 102 receives
the challenge code from the merchant system 106, the
user system requests a user identity code (e.g., a PIN)
WO 99/21321
PCT/US98/22162
-15-
from the user. In step 328, the user enters the PIN
for his or her first user identity.
In step 330 (Fig. 3B) , the user system 102
generates a real time digital signature, in dependence
5 upon the challenge code, the PIN entered with the first
user identity, and certain data regarding certain
listed components as presently existing in the user
system 102. The generation of the real time digital
signature in step 33 0 is described in more detail
10 below.
In step 332, the user system 102 transmits the
real time digital signature to the merchant system,
which in step 334 further transmits it on to the
certification server 104 together with the challenge
15 code and the user's payment information previously
supplied. In step 336, the certification server 104
combines the challenge code with the original signature
for the first user identity, as stored in the signature
database 108, and determines, in step 33 8, whether the
2 0 result matches the real time digital signature provided
by the user system 102 via the merchant system 106. If
the two results match, then the certification result is
positive (step 340) . If they differ, then the
certification result is negative (step 342) .
25 In step 344, the certification server 104
transmits the certification result back to the merchant
system 106 which, in step 346, either allows or
declines the purchases desired by the user.
Note that any or all of the communications called
3 0 for in Fig. 1 can be encrypted, digitally signed and/or
certified if desired in a given embodiment, although to
some extent these precautions might mitigate the
advantages obtained by the invention over prior
certification mechanisms. By avoiding these
WO 99/21321
PCT/US98/22162
-16-
precautions, certain requirements of current U.S.
export laws can be avoided as well.
As mentioned above, the original digital
signature generated by the user system 102 depends upon
5 both the user system 102 itself, as well as a user
identity. The user identity may be indicated by, for
example, a code or PIN entered by the user via the
keyboard. Alternatively, it might be more secure, for
example, by a fingerprint or a retinal scan taken by
10 the user system 102 of the user.
The portion of the original digital signature
which identifies the user system 102 itself, referred
to herein as a user system signature (USS) , can be
generated in a number of different ways in different
15 embodiments. One embodiment takes advantage of serial
numbers or other identifying data which may be present
in the user system, and which carry external assurances
of substantial uniqueness. That is, many computers
when manufactured are assigned a serial number or other
2 0 indicator which the manufacturer of the computer, or
some other authority, guarantees to be unique. For
example, Apple Macintosh computers, when manufactured,
are assigned an Ethernet address which is unique to
that specific computer. Alternatively, the identifier
2 5 can be assigned in software, such as in the operating
system of the computer. It is not essential that
whatever authority assigns the serial number guarantee
uniqueness; depending on the level of confidence
required by the merchant or the financial
3 0 clearinghouse, it may be sufficient only that it be
extremely unlikely that two computer systems which can
act as user systems 102 carry the same identifier.
This is the case where, for example, the number carries
WO 99/21321
PCT7US98/22162
-17-
external assurances of substantial uniqueness, such as
in the case of Ethernet addresses.
In another embodiment, the user system signature
does not rely on a component having an identifier that
5 carries external assurances of substantial uniqueness.
Instead, a plurality of components (hardware or
software) are examined to determine individual
component signatures. The individual component
signatures are then combined to form the overall user
10 system signature, or all of the individual component
data is digested together in a single pass. In one
embodiment, the individual component signatures are all
concatenated together in a predetermined sequence to
form the overall user system signature. The individual
15 component signatures may be digested prior to
concatenation in order to limit their size to the
predefined field size. In another embodiment,
optionally after digesting, the individual component
signatures are averaged or summed together to form the
2 0 overall user system signature. The individual
component signatures can be weighted prior to
combination, in order to reduce the impact on the user
system signature that would result from changes in
components that are more frequently subject to upgrade
25 or replacement.
In one embodiment, the user system 102 generates
the user system signature in dependence upon component
signatures from the following components, to the extent
present in the system. Except as indicated below, most
3 0 of the component signatures set forth in this list are
readable either from the CMOS or from a configuration
manager driver. For PCI or EISA systems, the data can
be read from the PCI or EISA board BIOS. The following
is only an illustrative list; other embodiments can
WO 99/21321
PCT/US98/22162
-18-
refer to other components not on this list. In
addition, different embodiments may or may not include
components which are readily removable by the user.
5 Hard Disk Drive
• drive I . D .
• numbers of cylinders, sectors and heads
• drive defective sector map (obtained from
sector 0)
10 • drive name
• drive manufacturer
• volume name
Floppy Disk Controller
15 • I/O addresses and settings
• interrupt assignments
• manufacturer name
Mo ni to r
• monitor name
2 0 • monitor type
Display Adaptor
• device name
• on -board memory
WO 99/21321
PCT/US98/22162
-19-
M other Boa r d
• CPU type
• CPU speed
• total memory present
5 • total cache present
• cache timings (measured empirically)
Ports
• I/O addresses and settings
• interrupt assignments
10 Sound, Video and Game Controllers
• device name
• driver name
• driver version
System Devices
15 • CMOS profile
The kinds of identifying data that might be used to
generate the individual component signatures can
include the manufacturer name, revision number,
versionnumber, date, release number, and so on.
2 0 In yet another embodiment, a combination of
individual component signatures also includes one or
more component signatures that carry external
assurances of substantial uniqueness, to the extent
such a component exists in the machine.
WO 99/21321
PCT/US98/22162
-20-
Fig. 4 is a flow chart detail of step 314 in
Fig. 3A, within which the user system creates the
original digital signature for the first user identity.
In a step 410, the user enters his or her PIN for the
5 first user identity. As mentioned, other forms of
identification might be used in different embodiments.
In step 412, the user system 102 determines whether it
has a component which bears an I.D. that carries
external assurances of substantial uniqueness. If so,
10 then in step 414, the USS is set equal to that
component I.D. In step 416, if the user system 102
does not have a component bearing an I.D. that carries
external assurances of substantial uniqueness, or if
the embodiment does not utilize such component I.D.s,
15 the user system 102 obtains data regarding each of the
listed components as they then exist in the user system
102. In a step 418, the user system 102 digests the
different data items and, in step 420, combines the
digested data items to form the USS. Any suitable
2 0 digesting algorithm can be used for the purpose of the
digesting step 418 including, for example, an error-
correcting code (ECC) generator or the well-known SHA-1
algorithm. The SHA-1 digesting algorithm is described
National Institute of Standards and Technology (NIST) ,
25 FIPS Publication 180: Secure Hash Standard (SHS) (May
1993) , as amended by National Institute of Standards
and Technology (NIST) Announcement of Weakness in the
Secure Hash Standard (May 1994) , both incorporated
herein by reference. Note that in a different
3 0 embodiment, the data from the individual components can
be combined (e.g., summed, averaged, concatenated
together, etc.) without digesting, and only the
combined version is digested.
WO 99/21321
PCT/US98/22162
-21-
In step 422 , the user system 102 combines the USS
either from step 420 or from step 414, with the first
user identity PIN as entered in step 410, and digests
the results again. Again, "combining" can include
5 adding or concatenating the PIN with the USS, or even
XOR-ing the PIN with the USS. Note that in a different
embodiment, the PIN can be combined with the individual
data items earlier in the process of Fig. 4, resulting
in only a single digesting step.
10 Fig. 5 is a flow chart detail of step 330
(Fig. 3B) , in which the user system generates the real
time signature in dependence upon the challenge code,
the PIN for the first user identity, and data regarding
listed components as presently existing in the user
15 system 102. The term "real time", as used herein, does
not require absolute currency. The term should be
interpreted loosely enough to include digital
signatures generated recently, but certainly more
recently than the time that the original digital
2 0 signature was generated. For example, instead of the
USS/PIN combination being calculated only in response
to an inquiry from an inquiring system, an embodiment
might request the user's PIN and generate the "real
time" USS/PIN combination on system boot. Another
25 embodiment might request the user's PIN and generate
the "real time" USS/PIN combination at the beginning of
the user's online session, for example when the user's
browser software begins executing. Another embodiment
might request the user's PIN and generate the "real
3 0 time" USS/PIN combination only in response to an
inquiry, but might then cache it for some period of
time thereafter.
Referring to Fig. 5, in step 510, the user system
102 determines whether it has a component bearing an
WO 99/21321
PCT/US98/22162
-22-
I.D. that carries external assurances of substantial
uniqueness. If so, then a real time USS is set equal
to such component I.D. If not, or if the embodiment
does not utilize components bearing an I.D. that
5 carries external assurances of substantial uniqueness,
then in step 514, the user system 102 obtains, in real
time, data regarding the listed components as presently
existing in the user system 102. In step 516, as in
step 418 in the flow chart of Fig. 4, the data items
10 are digested and, in step 518, a real time USS is
generated by combining the digested data items. The
real time USS is then further digested in step 52 0 with
the PIN entered in step 328 (Fig. 3A) for the first
user identity. As with the flow chart of Fig. 4, the
15 combining and digesting steps can be performed with
various algorithms in different embodiments. However,
the algorithms chosen should be such that the
signature, as it exists prior to step 522, should be
the same as the original digital signature generated in
2 0 the procedure of Fig. 4, given identical PINs and
identical user system components.
In step 522, the result of step 52 0 is further
combined with the challenge code and digested to
produce the real time digital signature that will
2 5 subsequently be provided to the merchant system 106 in
step 332 (Fig. 3B) .
It can be seen that the real time digital
signature must, in fact, be generated in real time (as
that term is used herein) if it is to incorporate the
30 challenge code provided by the merchant system 106.
The reliability of the real time signature in assuring
that the user system 102 on which it is generated is in
fact the same as the user system 102 on which the
original digital signature was generated, can be
WO 99/21321
PCT/US98/22162
-23-
compromised if the user system 102 stores the USS
locally in a form that can be pilfered. This risk is
minimized, as previously mentioned, by further
requiring the user to enter his or her PIN and
5 digesting it together with the USS. The user can still
compromise the reliability of the real time digital
signature by storing his or her PIN locally on the user
system 102, or by storing the original digital
signature itself locally on the user system 102, but
10 this is not an advisable procedure. The risk to the
merchant 106 or the financial clearinghouse 104 of such
a procedure can be minimized, for example by
contractually requiring the user to maintain better
security procedures, or by contractually assigning
15 liability to the user for any increased risk resulting
from inadequate PIN security.
Fig. 6 is a detail of step 336 (Fig. 3B) , in
which the certification server 104 combines the
challenge code with the original signature for the
20 first user identity, as stored in the signature
database 108. In step 610, in response to receipt of
the information from the merchant system 106, the
certification server retrieves the original signature
for the first user identity from the signature database
25 108. In step 612, the certification server combines
the original signature with the challenge code provided
by the merchant system 106 and digests them together in
the same manner as performed in step 522 (Fig. 5) .
As previously discussed, in step 338 (Fig. 3B) ,
3 0 if the original digital signature as combined (by the
certification server 104) with the challenge code
provided by the merchant system 106, does not match the
real time signature provided by the user system 102,
then the certification server has determined either
WO 99/21321
PCT/US98/22162
-24-
that the user system 102 on which the real time
signature was generated is not identical to the user
system 102 on which the original digital signature was
generated, or that the user identity code entered by
5 the user for the current transaction does not match the
user identity code entered by the user at the time of
original account establishment* Either conclusion
increases the likelihood that the current user is an
impostor. According to an aspect of the invention,
10 however, some flexibility can be applied to the
determination of whether the user system 102 is the
same system on which the original digital signature was
generated, allowing for a certain amount component
upgrade drift. Fig. 7 is a detail of the decision step
15 33 8 in Fig. 3B, which accommodates such flexibility.
In one such embodiment, the algorithms used to
generate the original and real time signatures involve
combining undigested individual system component data
prior to digesting. At the time of account
20 establishment, in addition to providing the original
signature to the certification server 104, the user
system 102 also digests individually the component data
that was used to generate the original signature, and
provides these individual component digests, together
25 with the user's PIN, to the certification server 104
for storage on the signature database 108 in
conjunction with the original digital signature. The
individual component signatures actually can be
digested prior to combining in the generation of the
3 0 original signature, but in order to minimize the risk
from unauthorized access to the signature database 108,
the digesting algorithm used to provide the individual
component digests to be stored on the signature
WO 99/21321
PCT/US98/22162
-25-
database 108 should be such that they cannot be used to
recreate the original USS .
Referring to Fig. 7, in step 710, the
certification server 104 determines whether the
5 original signature and challenge code combination is
exactly equal to the real time signature provided
through the merchant server 106. If so, then the
certification result is positive (step 712) . If not,
then in step 714, the certification server determines
10 whether the USS was based on a component having
external assurances of substantial uniqueness. If so,
then no drift is permitted in such a component and the
certification result is negative (step 716) .
In step 718, if the original signature and
15 challenge code combination is not exactly equal to the
real time signature, and individual user system
component signatures were used to generate a USS, then
in step 718, the certification server 104 requests the
individual user system component signatures as they
2 0 presently exist, from the user system 102 via the
merchant 106. In step 72 0, the user system 102
provides such information via the merchant 10 6 in the
same individually digested form with which they were
originally provided and stored on the signature
25 database 108. In step 722, the certification server
104 compares the individually digested real time user
system component signatures, newly received, to the
individually digested user system component signatures
previously stored in the signature database.
30 In step 724, the certification server 104
determines whether the difference exceeds some
predetermined threshold specified, for example, as a
number of component signatures which are permitted to
have changed. If the differences do not exceed the
WO 99/21321
PCT/US98/22162
-26-
designated threshold, then automatic reauthorization is
performed (step 1000) . If the differences does exceed
the predetermined threshold, then the certification
result is negative (step 728) .
5 Fig. 8 is a detail of step 724 (Fig. 7) in which
the certification server 104 determines whether the
difference between the two sets of individual component
signatures exceeds the predetermined threshold. The
flow chart set forth in Fig. 8 represents one
10 embodiment in which the threshold is specified as a
percentage. In a step 810, the certification server
104 calculates the weighted sum of the real time user
system component signatures. In step 812, the
certification server calculates the weighted sum of
15 user system component signatures as previously stored
in signature database 108. In step 814, the
certification server 104 determines whether the
difference between the two calculated values exceeds
the predetermined percentage threshold. If not, then
20 automatic reauthorization is permitted (step 1000) . If
so, then the certification result is negative (step
818) .
Fig. 9 is a detail of step 724 (Fig. 7) as
performed in a second embodiment, in which the maximum
25 upgrade drift flexibility is specified as a maximum
number of components whose individual component
signatures are permitted to have changed. In a step
910, the certification server counts the number of real
time provided component signatures which differ from
3 0 the corresponding component signatures as previously
stored. In step 912, the certification server
determines whether the count exceeds the predetermined
threshold. If not, then automatic reauthorization is
WO 99/21321
PCT/US98/22162
-27-
permitted (step 1000) . If so, then the certification
result is negative (step 916) .
Fig* 10 is a flow chart detail of step 1000
(Figs. 7, 8 and 9) . In step 1010, the certification
5 server 104 checks its log to determine whether the
user's user identity has received more than a
predetermined number of automatic reauthorizations. If
so, then the certification result is negative (step
1012) and reauthorization must take place manually. If
10 not, then in step 1014, the certification server
digests the newly received predigested component
signatures with the user's PIN already on file in the
signature database 108. In response to a request by
the certification server 104, the user system also
15 digests its newly digested component signatures with
the user's PIN, and transmits the result back to the
certification server 104 (step 1016) . In step 1018,
the certification server 104 determines whether the two
values are equal. If not, then in step 102 0, the
2 0 certification result is negative and automatic
reauthorization is aborted.
If the two numbers are equal, then automatic
reauthorization was successful. In order to update the
signature database 108, the channel between the user
25 system 102 and a certification server 104 optionally
now begins using a secure socket layer (SSL) (step
1022) . In step 1024, the user system 102 creates a new
original digital signature, using the undigested
individual component signatures and the user's PIN, and
30 transmits the result to the certification server 104.
In step 1026, the certification server 104 stores the
new individually digested component signatures, as well
as the new original signature received from step 1024,
in conjunction with the user account. In step 1028,
WO 99/21321
PCT/US98/22162
-28-
the certification server 104 increments the
reauthorization count in its log, and in step 1030 , the
communication channel between user system 102 and
certification server 104 exits the SSL protocol. Now
5 that reauthorization has taken place, in step 1032, the
certification server notifies the merchant system 106
to retry the transaction. Control then returns to step
324 (Fig. 3A) for the issuance of a new challenge code
to the user system 102.
10 As used herein, steps which take place "in
response to" a predecessor event, do so if the
predecessor event influenced the performance of such
steps. If there is an intervening time period, the
performance of the steps can still be considered
15 "responsive" to the predecessor event. If the
performance of the steps depends on more than one
predecessor event, then the steps are considered
performed in response to each of the predecessor
events .
2 0 The foregoing description of preferred
embodiments of the present invention has been provided
for the purposes of illustration and description. It
is not intended to be exhaustive or to limit the
invention to the precise forms disclosed. Obviously,
25 many modifications and variations will be apparent to
practitioners skilled in this art. For example, whereas
the flowcharts described herein illustrate steps being
performed in a particular sequence, it will be
appreciated that in many instances the sequence of the
3 0 steps can be reversed, or the steps can be performed in
a pipelined, overlapping manner, or both, without
departing from the scope of the invention. The
embodiments herein were chosen and described in order
to best explain the principles of the invention and its
WO 99/21321
PCT/US98/22162
-29-
practical application, thereby enabling others skilled
in the art to understand the invention for various
embodiments and with various modifications as are
suited to the particular use contemplated. It is
5 intended that the scope of the invention be defined by
the following claims and their equivalents.
WO 99/21321
PCT/US98/22162
-30-
CLAIMS
1 1. A digital certification method, comprising
2 the steps of :
3 storing, at a first time, a first signature
4 dependent upon a first user identity and a first user
5 system in combination;
6 generating, at a second time subsequent to said
7 first time, a second signature dependent upon a second
8 user identity and a second user system in combination;
9 and
10 certifying, in dependence upon said first and
11 second signatures, whether the combination of said
12 second user identity and said second user system match
13 the combination of said first user identity and said
14 first user system.
1 2. A method according to claim 1, wherein said
2 step of storing comprises the step of developing said
3 first signature in dependence upon a first user
4 identity code and in dependence further upon a first
5 group of at least one component as present in said
6 first user system at said first time.
1 3 . A method according to claim 2 , wherein said
2 step of developing said first signature comprises the
3 step of obtaining said first user identity code in
4 response to user input.
1 4. A method according to claim 2, wherein said
2 step of storing further comprises the step of storing
3 said first signature accessibly to a certification
4 server,
5 and wherein said step of certifying comprises the
6 step of said certification server developing a
WO 99/21321
PCT/US98/22162
-31-
7 certification result in dependence upon said first and
8 second signatures.
1 5. A method according to claim 1, wherein said
2 second user system is said first user system.
1 6. A method according to claim 1, wherein said
2 step of certifying comprises the step of certifying, in
3 dependence upon said first and second signatures,
4 whether the combination of said second user identity
5 and said second user system match the combination of
6 said first user identity and said first user system,
7 and further that said second signature was generated at
8 a time different from said first time.
1 7. A method according to claim 6, wherein said
2 step of generating is performed in response to a
3 challenge, wherein said second signature is further
4 dependent upon said challenge, and wherein said step of
5 certifying comprises the step of developing a
6 certification result in dependence upon said first and
7 second signatures and further in dependence upon said
8 challenge.
1 8. A method according to claim 1, further
2 comprising the step of providing a challenge code,
3 wherein said second signature is further
4 dependent upon said challenge code.
1 9. A method according to claim 8, wherein said
2 step of certifying comprises the step of developing a
3 certification result in dependence upon said first and
4 second signatures and further in dependence upon said
5 challenge code.
WO 99/21321
PCTYUS98/22162
-32-
1 10. A method according to claim 9, wherein said
2 step of storing a first signature comprises the step of
3 storing said first signature accessibly to a
4 certification server,
5 wherein said step of providing a challenge code
6 comprises the step of an inquiring system providing
7 said challenge code to both said second user system and
8 said certification server,
9 wherein said step of generating a second
10 signature comprises the step of said second user system
11 generating said second signature, said second signature
12 being provided to said certification server,
13 and wherein said step of developing a
14 certification result is performed by said certification
15 server.
1 11. A method according to claim 10, wherein said
2 step of certifying further comprises the step of
3 providing said certification result to said inquiring
4 system.
1 12. A method according to claim 1, wherein said
2 step of storing a first signature comprises the step of
3 storing said first signature accessibly to a
4 certification server, and wherein said first user
5 system comprises a first group of components,
6 comprising the steps of:
7 developing a first component signature of each
8 respective component in said first group as present in
9 said first user system at said first time; and
10 storing said first component signatures
11 accessibly to said certification server.
WO 99/21321
PCT7US98/22162
-33-
1 13 . A method according to claim 12 , wherein said
2 second user system comprises a second group of
3 components, wherein said first signature is different
4 from said first component signatures, wherein said step
5 of certifying comprises the step of said certification
6 server determining, in dependence upon said first and
7 second signatures, that the combination of said second
8 user identity and said second user system does not
9 match the combination of said first user identity and
10 said first user system, further comprising the steps
11 of:
12 developing a second component signature of each
13 respective component in said second group as present in
14 said second user system at said second time; and
15 said certification server comparing said second
16 component signatures with said first component
17 signatures to determine whether said first and second
18 user systems satisfy predetermined drift criteria*
1 14. A method according to claim 13, wherein said
2 step of comparing comprises the step of determining
3 whether a count of the number of said second component
4 signatures which differ from corresponding first
5 component signatures exceeds a predetermined maximum
6 drift number greater than zero.
1 15. A method according to claim 13, wherein said
2 step of certifying further comprises the step of
3 determining whether said second user identity code is
4 equal to said first user identity code.
1 16. A digital certification method, comprising
2 the steps of:
WO 99/21321
PCT/US98/22162
-34-
3 storing, accessibly to a certification server, a
4 first signature of a first user identity on a first
5 user system in dependence upon a first user identity
6 code and in dependence further upon a first group of at
7 least one component as present in said first user
8 system at a first time;
9 at a second time subsequent to said first time,
10 an inquiring system providing a challenge code to a
11 second user system and said second user system
12 developing a second signature in dependence upon a
13 second user identity code and in dependence further
14 upon a second group of at least one component as
15 present in said second user system at said second time;
16 providing said challenge code and said second
17 signature to said certification server; and
18 said certification server developing a
19 certification result in dependence upon said second
2 0 signature and a combination of said challenge code and
21 said first signature.
1 17. A method according to claim 16, further
2 comprising the step of communicating said certification
3 result to said inquiring system.
1 18. A digital certification method, comprising
2 the steps of:
3 forming, at a first time, a first signature
4 dependent upon a first user identity and a first user
5 system in combination;
6 providing said first signature to a certification
7 server;
8 generating, in response to an inquiry from an
9 inquiring system at a second time subsequent to said
10 first time, a second signature dependent upon a second
WO 99/21321
PCT/US98/22162
-35-
11 user identity and a second user system in combination;
12 and
13 providing said second signature for comparison
14 with said first signature.
1 19 . A method according to claim 18, wherein said
2 step of forming a first signature comprises the step of
3 developing said first signature in dependence upon a
4 first user identity code and in dependence further upon
5 a first group of at least one component as present in
6 said first user system at said first time.
1 2 0. A method according to claim 19, wherein said
2 step of developing said first signature comprises the
3 step of obtaining said first user identity code in
4 response to user input.
1 21. A method according to claim 18, wherein said
2 second user system is said first user system.
1 22. A method according to claim 18, wherein said
2 second signature is further dependent upon said
3 inquiry.
1 23. A method according to claim 18, wherein said
2 second user system receives a challenge code in
3 conjunction with said inquiry,
4 and wherein said second signature is further
5 dependent upon said challenge code.
1 24. A method according to claim 18, wherein said
2 first user system comprises a first group of
3 components,
4 comprising the steps of:
WO 99/21321
PCT/US98/22162
-36-
5 developing a first component signature of each
6 respective component in said first group as present in
7 said first user system at said first time; and
8 providing said first component signatures to said
9 certification server.
1 25. A method according to claim 24, wherein said
2 second user system comprises a second group of
3 components, wherein said first signature is different
4 from said first component signatures, and wherein the
5 combination of said second user identity and said
6 second user system does not match the combination of
7 said first user identity and said first user system,
8 further comprising the steps of:
9 developing a second component signature of each
10 respective component in said second group as present in
11 said second user system at said second time; and
12 providing said second component signatures for
13 comparison with said first component signatures.
1 26. A digital certification method, comprising
2 the steps of:
3 providing a challenge code to a user system in
4 response to a request for authorization for said user
5 system;
6 receiving a real time signature from said user
7 system after said step of providing a challenge code;
8 providing said challenge code and said real time
9 signature to a certification server; and
10 receiving a certification result from said
11 certification server after said step of providing said
12 challenge code and said real time signature to said
13 certification server.
WO 99/21321
PCT/US98/22162
-37-
1 27. A method according to claim 26, wherein said
2 real time signature is dependent upon a first user
3 identity and said user system in combination.
1 2 8. A method according to claim 27, wherein said
2 real time signature is further dependent upon said
3 challenge code.
1 29. A digital certification method, comprising
2 the steps of:
3 storing accessibly to a certification server, at
4 a first time, a first signature dependent upon a first
5 user identity and a first user system in combination;
6 receiving, at a second time subsequent to said
7 first time, a second signature dependent upon a second
8 user identity and a second user system in combination;
9 and
10 certifying, in dependence upon said first and
11 second signatures, whether the combination of said
12 second user identity and said second user system match
13 the combination of said first user identity and said
14 first user system.
1 30. A method according to claim 29, wherein said
2 second user system is said first user system.
1 31. A method according to claim 29, wherein said
2 step of certifying comprises the step of certifying, in
3 dependence upon said first and second signatures,
4 whether the combination of said second user identity
5 and said second user system match the combination of
6 said first user identity and said first user system,
7 and that said second signature was generated at a time
8 different from said first time.
WO 99/21321
PCT/US98/22162
-38-
1 32. A method according to claim 29 , further
2 comprising the step of receiving, in conjunction with
3 said step of receiving a second signature, a copy of a
4 chal 1 enge code ,
5 wherein said second signature is further
6 dependent upon said challenge code.
1 3 3. A method according to claim 32, wherein said
2 step of certifying comprises the step of developing a
3 certification result in dependence upon said first and
4 second signatures and further in dependence upon said
5 challenge code.
1 34. A method according to claim 29, wherein said
2 step of certifying further comprises the step of
3 providing a certification result to an inquiring
4 system.
1 35. A method according to claim 29, wherein said
2 first user system comprises a first group of
3 components, comprising the steps of:
4 receiving a first component signature of each
5 respective component in said first group as present in
6 said first user system at said first time; and
7 storing said first component signatures
8 accessibly to said certification server.
1 36. A method according to claim 35, wherein said
2 second user system comprises a second group of
3 components, wherein said first signature is different
4 from said first component signatures, wherein said step
5 of certifying comprises the step of said certification
6 server determining, in dependence upon said first and
WO 99/21321
PCT/US98/22162
-39-
7 second signatures, that the combination of said second
8 user identity and said second user system does not
9 match the combination of said first user identity and
10 said first user system, further comprising the steps
11 of:
12 receiving a second component signature of each
13 respective component in said second group as present in
14 said second user system at said second time; and
15 said certification server comparing said second
16 component signatures with said first component
17 signatures to determine whether said first and second
18 user systems satisfy predetermined drift criteria.
1 3 7. A method according to claim 36, wherein said
2 step of comparing comprises the step of determining
3 whether a count of the number of said second component
4 signatures which differ from corresponding first
5 component signatures exceeds a predetermined maximum
6 drift number greater than zero.
1 3 8. A method according to claim 36, wherein said
2 step of certifying further comprises the step of
3 determining whether said second user identity code is
4 equal to said first user identity code.
1/11
PCT/US98/22162
L
MERCHANT
(INQUIRER)
106
i. Real Time
Signature
Original
Signature
5. Payment Info
;f Real Time Signature
+ Challenge Code
6. Certification^
Result
104
. FINANCIAL
CLEARINGHOUSE
(TRUSTED CERTIFICATION
SERVER)
FIG. 1
SIGNATURE
DATABASE
SUBSTITUTE SHEET (RULE 26)
WO 99/21321 PCT/US98/22162
2/11
CPU
BUS
L
202
CPU
L
204
CACHE
MEMORY
■206
■208
INTERFACE
CIRCUITRY
L
210
MAIN
MEMORY
PCI ISA
BUS BUS
212-
r
232
NETWORK
ADAPTER
NETWORK
-214
222
DISK
DRIVE
CONTROLLER
CD-ROM
DRIVE
CONTROLLER
FLOPPY
DRIVE
CONTROLLER
I/O
PORTS
SOUND
GAME
CONTROLLER
BOOT
PROM
DISPLAY
ADAPTER
-230
-218
220
FIG. 2
SUBSTITUTE SHEET (RULE 26)
WO 99/21321
PCT/US98/22162
3/11
OVERALL SYSTEM FLOW
USER PRESENTS IDENTIFICATION TO FINANCIAL
INSTITUTION
FINANCIAL INSTITUTION ESTABLISHES ACCOUNT FOR USER
USER, AT USER SYSTEM , CREATES ORIGINAL SIGNATURE
FOR FIRST USER IDENTITY
USER SYSTEM TRANSMITS ORIGINAL SIGNATURE TO
CERTIFICATION SERVER
CERTIFICATION SERVER STORES ORIGINAL SIGNATURE IN
SIGNATURE DATABASE IN CONJUNCTION WITH USER
ACCOUNT
USER BROWSES MERCHANT'S ONLINE CATALOG, SELECTS
ITEMS FOR PURCHASE
USER SYSTEM TRANSMITS PAYMENT INFORMATION TO
MERCHANT SYSTEM
MERCHANT SYSTEM GENERATES CHALLENGE CODE,
TRANSMITS TO USER SYSTEM
USER SYSTEM REQUESTS PIN FROM USER
USER ENTERS PIN FOR FIRST USER IDENTITY
310
312
■314
■316
-318
-320
-322
-324
326
-328
FIG. 3A
SUBSTITUTE SHEET (RULE 26)
WO 99/21321
PCT/US98/22162
4/11
340
©
USER SYSTEM GENERATES REAL TIME SIGNATURE IN
DEPENDENCE UPON CHALLENGE CODE, PIN FOR FIRST
USER IDENTITY, AND DATA REGARDING LISTED
COMPONENTS AS PRESENTLY EXISTING IN USER SYSTEM
USER SYSTEM TRANSMITS REAL TIME SIGNATURE TO
MERCHANT SYSTEM
MERCHANT SYSTEM TRANSMITS PAYMENT INFORMATION,
REAL TIME SIGNATURE, AND CHALLENGE CODE TO
CERTIFICATION SERVER
CERTIFICATION SERVER COMBINES CHALLENGE CODE
WITH ORIGINAL SIGNATURE FOR FIRST USER IDENTITY, AS
STORED IN SIGNATURE DATABASE
338
CERTIFICATION RESULT IS
POSITIVE
YES
-330
-332
334
L
■336
342
CERTIFICATION RESULT IS
NEGATIVE
CERTIFICATION SERVER TRANSMITS CERTIFICATION
RESULT TO MERCHANT SYSTEM
MERCHANT SYSTEM ALLOWS/DECLINES PURCHASE, AND
SO NOTIFIES USER SYSTEM.
-344
346
FIG. 3B
SUBSTITUTE SHEET (RULE 26)
WO 99/21321
5/11
PCT/US98/22162
CREATE ORIGINAL ^
SIGNATURE FOR FIRST
USER IDENTITY
■314
410
USER ENTERS PIN FOR FIRST USER IDENTITY
DOES
USER SYSTEM'
HAVE A COMPONENT
HAVING AN ID THAT
CARRIES EXTERNAL
ASSURANCES OF
SUBSTANTIAL
UNIQUENESS
-412
414
YES
USS =
COMPONENT
ID
OBTAIN DATA REGARDING LISTED COMPONENTS PRESENT
IN USER SYSTEM
-416
DIGEST DATA ITEMS
USS = COMBINED DATA ITEMS
DIGEST USS WITH FIRST USER IDENTITY PIN
FIG. 4
SUBSTITUTE SHEET (RULE 26)
WO 99/21321
6/11
PCT/US98/22162
■330
GENERATE REAL TIME
SIGNATURE
DOES
USER SYSTEM'
HAVE A COMPONENT
HAVING AN ID THAT
CARRIES EXTERNAL
ASSURANCES OF
SUBSTANTIAL
UNIQUENESS.
7
-510
YES
512
REAL TIME
USS =
COMPONENT
ID
NO
OBTAIN DATA REGARDING LISTED COMPONENTS PRESENT
IN USER SYSTEM
DIGEST DATA ITEMS
516
REAL TIME USS = COMBINED DATA ITEMS
DIGEST REAL TIME USS WITH FIRST USER IDENTITY PIN
DIGEST RESULT WITH CHALLENGE CODE
-514
-518
520
522
FIG. 5
SUBSTITUTE SHEET (RULE 26)
WO 99/21321
7/11
PCT/US98/22162
■336
CERTIFICATION SERVER COMBINES CHALLENGE CODE
WITH ORIGINAL SIGNATURE FOR FIRST USER IDENTITY, AS
STORED IN SIGNATURE DATABASE
CERTIFICATION SERVER
RETRIEVES ORIGINAL
SIGNATURE FOR FIRST
USER IDENTITY FROM
SIGNATURE DATABASE
610
CERTIFICATION SERVER
DIGESTS ORIGINAL
SIGNATURE WITH
CHALLENGE CODE
612
FIG. 6
SUBSTITUTE SHEET (RULE 26)
WO 99/21321
8/Ii
PCT/US98/22162
DOES ORIGINAL SIGNATURE + CHALLENGE CODE
COMBINATION MATCH REAL TIME SIGNATURE?
■338
712
CERTIFICATION
RESULT IS
POSITIVE
YES
IS
ORIGINAL SIGNATURE
+ CHALLENGE CODE
COMBINATION EQUAL TO
REAL TIME
SIGNATURE
9
-710
-714
IS
USS BASED
^ON COMPONENT HAVING^
EXTERNAL ASSURANCES
OF SUBSTANTIAL
UNIQUENESS
.YES
L
716
CERTIFICATION
RESULT IS
NEGATIVE
NO
CERTIFICATION SERVER REQUESTS INDIVIDUAL USER
SYSTEM COMPONENT SIGNATURES FROM USER SYSTEM
VIA MERCHANT
USER SYSTEM PROVIDES INDIVIDUAL USER SYSTEM
COMPONENT SIGNATURES TO CERTIFICATION SERVER VIA
MERCHANT SYSTEM
CERTIFICATION SERVER COMPARES REAL TIME USER
SYSTEM COMPONENT SIGNATURES TO USER SYSTEM
COMPONENT SIGNATURES PREVIOUSLY STORED IN
SIGNATURE DATABASE
1000
■724
■718
720
■722
AUTOMATIC-
ALLY
REAUTHORIZE
DOES
DIFFERENCE EXCEED
PREDETERMINED
THRESHOLD
YES
f
728
CERTIFICATION
RESULT IS
NEGATIVE
FIG. 7
SUBSTITUTE SHEET (RULE 26)
WO 99/21321
9/11
PCT/US98/22162
DOES DIFFERENCE BETWEEN ORIGINAL AND REAL TIME
USS'S EXCEED PREDETERMINED THRESHOLD?
CERTIFICATION SERVER CALCULATES WEIGHTED SUM OF
REAL TIME USER SYSTEM COMPONENT SIGNATURES
CERTIFICATION SERVER CALCULATES WEIGHTED SUM OF
PREVIOUSLY STORED USER SYSTEM COMPONENT
SIGNATURES
1000
AUTOMATIC-
NO
ALLY
REAUTHORIZE
DOES
DIFFERENCE EXCEED
PREDETERMINED
THRESHOLD
9
-724
810
812
818
YES
CERTIFICATION
RESULT IS
NEGATIVE
FIG. 8
SUBSTITUTE SHEET (RULE 26)
WO 99/21321
10/11
PCT/US98/22162
DOES DIFFERENCE BETWEEN ORIGINAL AND REAL TIME
USS'S EXCEED PREDETERMINED THRESHOLD?
CERTIFICATION SERVER COUNTS NUMBER OF REAL TIME
PROVIDED COMPONENT SIGNATURES WHICH DIFFER FROM
CORRESPONDING COMPONENT SIGNATURES AS
PREVIOUSLY STORED
724
910
1000
916
AUTOMATIC-
NO <
ALLY
REAUTHORIZE
DOES
DIFFERENCE EXCEED
PREDETERMINED
THRESHOLD
9
YES
CERTIFICATION
RESULT IS
NEGATIVE
FIG. 9
SUBSTITUTE SHEET (RULE 26)
WO 99/21321
PCT/US98/22162
AUTOMATIC REAUTHORIZATION
LOG
SHOWS
TOO MANY
REAUTHORIZATIONS .
?
NO
1010
L
^1000
1012
YES
CERTIFICATION
RESULT IS
NEGATIVE
CERTIFICATION SERVER DIGESTS NEWLY RECEIVED PRE-
DIGESTED COMPONENT SIGNATURES WITH PIN ON FILE
USER SYSTEM DIGESTS NEWLY DIGESTED COMPONENT
SIGNATURES WITH PIN, SENDS TO CERTIFICATION SERVER
L
-1014
1016
1020
CERTIFICATION
RESULT IS
NEGATIVE
BEGIN SSL PROTOCOL
-1022
USER SYSTEM CREATES NEW ORIGINAL SIGNATURE,
TRANSMITS TO CERTIFICATION SERVER
CERTIFICATION SERVER STORES NEW INDIVIDUALLY
DIGESTED COMPONENT SIGNATURES AND NEW ORIGINAL
SIGNATURE IN CONJUNCTION WITH USER ACCOUNT
CERTIFICATION SERVER INCREMENTS REAUTHORIZATION
COUNT IN LOG
■1024
■1026
1028
END SSL PROTOCOL
1030
CERTIFICATION SERVER NOTIFIES MERCHANT SYSTEM TO
RE-TRY THE TRANSACTION
1032
FIG. 10
SUBSTITUTE SHEET (RULE 26)
INTERNATIONAL SEARCH REPORT
International application No.
PCT/US98/22162
A. CLASSIFICATION OF SUBJECT MATTER
IPC(6) :H04L 9/32
US CL :380/25, 23
According to International Patent Classification (IPC) or to both national classification and IPC
R FIELDS SEARCHED
Minimum documentation searched (classification system followed by classification symbols)
U.S. : 380/25,23
Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched
Electronic data base consulted during the international search (name of data base and, where practicable, search terms used)
Please See Extra Sheet.
DOCUMENTS CONSIDERED TO BE RELEVANT
Category*
Citation of document, with indication, where appropriate, of the relevant passages
Relevant to claim No.
x,p
Y,P
Y,P
A,P
US 5,721,780 A (Ensor et al.) 24 February 1998 (24.02.98)
abstract
column 2, lines 18-51
column 5, lines 22-32
FIGS 2 & 3
US 5,796,840 A (Davis) 18 August 1998 (18.08.98)
Figure 8
column 7, lines 15-44
US 5,774,550 A (Brinkmeyer et al.) 30 June 1998 (30.06.98)
1-6, 18-21,29-31
7-9
7-9,
All
P^j Further documents are listed in the continuation of Box C. | ""| See patent family annex.
■L"
"O"
Special categories of cited documents:
document defining the general state of the art which is not considered
to be of particular relevance
earlier document published on or after the international filing date
document which may throw doubts on priority claim(s) or which is
cited to establish the publication date of another citation or other
special reason (as specified)
document referring to an oral disclosure, use, exhibition or other
document published prior to the international filing date but later than
the priority date claimed
later document published after the international filing date or priority
date and not in conflict with the application but cited to understand
the principle or theory underlying the invention
document of particular relevance; the claimed invention cannot be
considered novel or cannot be considered to involve an inventive step
when the document is taken alone
document of particular relevance; the claimed invention cannot be
considered to involve an inventive step when the document is
combined with one or more other such documents, such combination
being obvious to a person skilled in the art
document member of the same patent family
Date of the actual completion of the international search
22 DECEMBER 1998
Date of mailing of the international search report
22 FEB 1D99
Name and mailing address of the ISA/US
Commissioner of Patents and Trademarks
Box PCT
Washington, D.C. 20231
Facsimile No. (703) 305-3230
Authorized officer
KEISHA Y. SOLOMON ^^G 4 ^ ^ aJ-^
Telephone No. 703-305-1373
Form PCT/ISA/210 (second sheetXJuly 1992)*
INTERNATIONAL SEARCH REPORT
International application No.
PCT/US98/22162
B. FIELDS SEARCHED
Electronic data bases consulted (Name of data base and where practicable terms used):
APS, NPL, WEST, DERWENT, WWW
digital certification/certificate/signature,
"digital certification of user and computer",
encrypt, drift criteria/number, challenge code,
Form PCT/ISA/210 (extra sheetXJuly 1992)*